There are various reasons why network operators desire to measure traffic in their networks. Network measurement, for example, provides the data required for better network control, enabling the operator to characterize the state of the network, the traffic demands, and the actual consumption of network resources. Network measurement also enables trouble shooting or even prevent service-level agreement (SLA) violations before they occur.
With recent technological advancements such as Software-Defined Networking (SDN) and Network Function Virtualization (NFV), operators have coined the term “service chaining” to mean the differentiated forwarding of traffic flows across a policy defined set of middle boxes (also commonly referred to as services, inline services, appliances, network functions/vNFs in case of NFV, or Service Functions (SF)). Examples SFs include firewalls, content filters, Intrusion Detection Systems (IDS), Deep Packet Inspection (DPI), Network Address Translation (NAT), content caches, load-balancers, Wide Area Network (WAN) accelerators, multimedia transcoders, logging/metering/charging/advanced charging applications, etc
Service chaining requires a classification process to forward packets on the correct service chain, followed by the differentiated forwarding/routing of the traffic flow across the right set of SFs or service function chain (SFC). Given the importance of this networking use case, the Internet Engineering Task Force (IETF) is developing protocols that will allow more efficient ways to implement SFCs. The IETF is even working on the definition of a Network Service Header (NSH) that will be applied to packets by the classifier. Then Service Function Forwarders (SFFs) will create the Service Function Paths (SFP) in the form of an overlay. IETF' s solution is applicable to both physical Network Functions (NF) and virtual NFs (vNF) as defined by ETSI Network Functions Virtualization (NFV), referred to as SF in IETF.
A conventional approach for tracking packets that traverse the service chain includes a classifier (e.g., a Deep Packet Inspection (DPI) or Shallow Packet Inspection (SPI)) identifying the packet as belonging to a specific flow, wherein each flow is associated with a set of rules configured by a policy. The classifier then notifies a controller (e.g., a Software Defined Network (SDN) controller) each time a packet flow that matches the rule is observed. In that notification the classifier includes the flow information (e.g., 5 tuple packet header information). In response, the controller would have to program the switches (some or all) along the path of the flow to perform the appropriate type of counting/monitoring on packets with that flow information (e.g., 5 tuple). Such a conventional approach suffers the following limitations: 1) the controller would have to be aware of the path the flow will traverse; 2) there is a time between when the classifier identifies a flow, notifies the controller, and the controller programs the switches. During that time packets belonging to the flow are not monitored/counted. As a result the obtained measurement/monitoring information may be outdated or inaccurate; and 3) sending flow identification and notification to the controller generates control plane messaging. This sets a limit on how granular the counting/monitoring tasks can be.